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(54) Abstract Title 

Enhanced cordless telephone platform using Bluetooth (rtm) technology 



(57) A cordless telephone 210,220 using Bluetooth wireless links is presented. A Bluetooth voice data 
structure is implemented by coding the voice data at a bitrate below 64 kb/s, such that the full number of 
payload bits provided by the Bluetooth voice data structure are not required for transmission of voice data. 
The packet payload is then encoded, possibly in a non-standard format to implement a robust error detection 
and/or correction protocol for the voice data, as well as for the provision of a low-rate data channel for 
transmission of information such as caller ID. Alternatively, a Bluetooth non-voice data structure can be 
employed by transmitting encoded voice data as user payload bits. The data link is then flushed each time new 
voice data is ready for sending by the transmitting device. If slots are available before the data link is flushed, 
unsuccessfully transmitted data can be automatically resent, thereby implementing time and frequency 
diversity. 





Note: HV3* is a modified form of the HV3 format 
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TITLE OF THE INVENTION 

Enhanced Cordless Telephone Platform using Bluetooth Technology 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

This invention relates in general to a cordless telephone system. In particular, 
the invention relates to the implementation of a cordless telephone system using the 
Bluetooth wireless digital communications standard. 

2. Background Art 

Bluetooth is an emerging wireless standard, operating in the 2.4GHz ISM band 
world-wide. Although originally developed for use in the mobile phone industry, 
widespread adoption within the consumer electronics industry suggests that it is likely to 
become a popular and commonplace home wireless standard in the coming years. 
Due to it's predicted penetration into the consumer market, it is of considerable interest 
to use the Bluetooth standard as the bearer for a cordless telephone system. 

In it's basic form, a cordless system consists of a basestation that is connected 
to the Public Switched Telephone Network ("PSTN") and that communicates wirelessly 
to a handset. The principal channel between the basestation and handset is voice data 
(the telephone call), although there is typically also a small amount of control data and 
information to be exchanged. The system can be (and has been) extended to multiple 
PSTN connections and multiple handsets. 

Several characteristics for a wireless communications link may be desirable in 
implementing a cordless telephony platform. Such characteristics include: 1) the 
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provision of at least two full-duplex voice links to support multiple handsets; 2) a low- 
speed data link in parallel with voice links for system communication such as caller ID 
information; 3) a high-speed data link to provide for transmission of call setup 
information with minimal delay; 4) robust error detection and/or error correction on 
voice and data links to ensure high-quality and uninterrupted communications; and 5) 
implementation of one or more high speed data links in parallel with the voice link(s). 

However, the transmission formats defined by the Bluetooth specification do not 
provide a combination of these characteristics that is typically desirable for cordless 
telephony. Three Synchronous Connection-Oriented ("SCO") packet types are defined 
in the Bluetooth standard specifically for voice transmission (namely, HV1 , HV2 and 
HV3). A SCO link is a point-to-point, circuit-switched connection between a master and 
a slave. The Bluetooth SCO links employ varying error correction schemes where 
Forward Error Correction ("FEC") may or may not be available to protect the transmitted 
data. HV1 uses 1/3 rate FEC and allows 10 bytes of data; HV2 uses 2/3 rate FEC and 
allows 20 bytes of data; and HV3 uses no FEC and allows 30 bytes of data. The 
packet header is always protected by 1/3 rate FEC. 

Bluetooth's HV1 format occupies the complete channel bandwidth for a single 
link, and is thus unable to support multiple handsets or a parallel data channel. In 
contrast, the HV3 link occupies a reduced bandwidth but does not contain error 
detection which is required for implementation of a high-quality voice link. The HV2 
format allows two full-duplex voice links but lacks desirable parallel data capability. 
Such parallel data capabilities may be a primary motivation for moving to a Bluetooth 
wireless bearer. Furthermore, even Bluetooth's voice links which provide error 
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correction do not provide error detection. Therefore, packets with errors that are not 
properly corrected cannot be readily muted, potentially exposing the data recipient to 
unpleasant audible noise. 

Thus, the voice formats defined by the Bluetooth standard are unsatisfactory for 
many advanced cordless telephone applications. However, if the limitations of the 
formats could be overcome, it would be desirable to implement a Bluetooth-based 
cordless telephone system so that the base unit can also serve as a Bluetooth gateway, 
thereby enabling advanced communications with a variety of electronic devices with 
minimal added expense. 
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SUMMARY OF THE INVENTION 

A technique for transmitting voice data via a Bluetooth communications link is 
presented. A synchronous Bluetooth link can be implemented to provide improved 
error detection capabilities and/or parallel data communications capabilities. The audio 
data is encoded at a bitrate less than that specified for the synchronous link. The link 
packet payload is then encoded to comprise the audio data and an error detection field. 
A parallel data channel may also be encoded within the packet payload. Upon receipt 
of the packet by a second device, the packet payload is decoded and the digitized 
audio data is extracted and verified. 

An asynchronous Bluetooth link can also be implemented to provide improved 
error detection capabilities, parallel data communications and/or a greater number of 
simultaneous cordless telephone links. The asynchronous link packet payloads are 
formed including digitized audio data and various other information. Each packet is 
then transmitted. Transmissions can be repeated on subsequent time slots if an 
acknowledgement is not received, or if the link is flushed. The link is flushed each time 
new digitized audio data is presented for transmission. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a block diagram of a cordless telephony system based upon a base 
station serving as a Bluetooth gateway for communication with a variety of Bluetooth- 
enabled devices. 

Figure 2 is a Bluetooth-based cordless telephone system using modified HV3 
links for telephonic communications. 

Figure 3 is an embodiment of an HV3 data packet modified for telephonic 
applications, in accordance with one aspect of the invention. 

Figure 4 is an embodiment of a DM3 data packet with payload adapted for 
telephonic communications, in accordance with another aspect of the invention. 

Figure 5 is a chart illustrating transmissions over time of a cordless telephone 
voice data using an asynchronous Bluetooth data link. 

Figure 6 illustrates a cordless telephone system using asynchronous Bluetooth 
data links for voice transmission. 

Figure 7 is a functional block diagram of a voice communications path from a 
cordless telephone base station to a handset. 
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DETAILED DESCRIPTION OF THE INVENTION 

While this invention is susceptible to embodiment in many different forms, there 
are shown in the drawings and will be described in detail herein specific embodiments. 
The present disclosure is to be considered as an exemplification of the principle of the 
invention intended merely to explain and illustrate the invention, and is not intended to 
limit the invention in any way to embodiments illustrated. 

One advantage of using the Bluetooth standard as a wireless bearer is to 
additionally allow the wireless communication of data (as opposed to voice) between 
the basestation and various data terminals. In this context, the basestation would be 
termed a gateway. An example embodiment of this type of system including cordless 
telephone functionality is shown in Figure 1. The system of Figure 1 implements a 
proprietary link based upon the Bluetooth air interface for communications between 
gateway 100 and cordless telephony devices such as handsets 110 and 120 or 
cordless telephone headset 130. However, gateway 100 is likewise fully capable of 
communicating via conventional Bluetooth links with other Bluetooth-enabled devices, 
such as personal computer 140, mobile phone handset 150 or Bluetooth-enabled 
appliance 160. 

In the embodiment of Figure 1 , base station 100 is provided with the capability of 
querying other Bluetooth-based devices to determine which, if any, available devices 
are capable of communicating via an appropriate proprietary extension of the Bluetooth 
protocol. One mechanism that can be used to implement such a query is the Service 
Discovery Protocol ("SDP") defined under the Bluetooth protocol set. This mechanism 
allows for identifying the specific classes of service that are available for use. SDP 
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further allows for the retrieval of attributes that are needed to connect to a chosen 
service. Thus, attributes required to defined proprietary services can be configured and 
communicated using SDP. 

For significant multi-handset capabilities under the standard Bluetooth 
specifications, the HV3 structure could be used. As defined by Bluetooth, the HV3 
structure allows up to three full-duplex voice links to be established. However, the 
Bluetooth specification provides no error detection or correction on HV3 voice data. 
This is a serious disadvantage for a voice system since it will not be possible to mute 
the audio during periods of bad interference. As a result, the users may be subjected to 
harsh and annoying audible noise when communication errors occur. 

The HV2 format defined by Bluetooth allows for two active duplex links with error 
correction and thus is another potential format for use in a cordless system. However, 
one disadvantage of using HV2 is that, if both voice links are active, there is no 
bandwidth available for parallel data, thus impairing the functionality of the cordless 
telephone system. A fully-functional HV2-based system would be possible if it was 
restricted to one active handset plus data. While additional handsets could be 
provided, only one could be active at one time. Furthermore, while HV2 provides for 
error correction, it does not provide for error detection. Thus, when the provided FEC 
capabilities are insufficient to correct an error, erroneous data is processed, potentially 
subjecting the user to hard and annoying audible noise. 

The specifications of the Bluetooth standard can be augmented to overcome 
such drawbacks and to implement a fully-functional multi-handset cordless telephone 
system using the Bluetooth standard as the wireless bearer. Moreover, by 
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implementing the augmentations as proprietary extensions for communicating with 
proprietary handsets, the base unit remains free to engage in communications with 
other non-proprietary Bluetooth-enabled devices, serving as a Bluetooth gateway, with 
minimal extra cost or complexity of design. 

One of the key issues with using a standard Bluetooth format for a cordless 
system is the number of active voice channels that can be supported. As explained 
above, the number of cordless channels using the standard formats is effectively limited 
to two (with no bandwidth remaining for an independent data channel) or one (with 
enough bandwidth remaining to support an independent data channel). However, 
multiple-handset telephone systems are becoming increasingly popular and desirable. 
Therefore, an increase in the number of channels that can be supported with high- 
quality links and full-featured communications capabilities is of great importance. 

Figure 2 illustrates another embodiment of a cordless telephone system in which 
base station 200 serves as a gateway to communicate with conventional Bluetooth- 
enabled devices such as personal computer 230, which simultaneously being capable 
of communications with cordless telephone handsets 210 and 220 using a proprietary 
extension of a standard Bluetooth HV3 link, such as a link comprised of HV3 packets 
with altered payload structures. 

Figure 3 illustrates such an altered HV3 payload structure according to one 
possible embodiment of the invention, which can be used in communications between 
base station 200 and cordless handsets 210 and 220. The HV3 packet structure is 
maintained, but the traffic contained within it is further encoded. HV3 normally provides 
240 payload bits per packet with no error correction or detection. A compliant Bluetooth 
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system must support 64 kb/s CVSD (Continuous Variable Slope Delta) Modulation for 
encoding of audible information, and may also support 64 kb/s log PCM format (A-law 
or p-law), Implemented with 64 kb/s voice coding according to the Bluetooth 
specification. Using the specified voice encoders, an HV3 packet transports 3.75ms of 
speech and HV3 can support up to 3 duplex voice links. However, the lack of data 
capacity and error detection makes HV3 only marginally useful in a cordless system. 

Therefore, the modified HV3 payload structure of Figure 3 includes voice data 
field 320 which contains audible information encoded at 32 kbps using an ADPCM 
format. This format provides sufficient audio quality for high-quality telephonic 
communications. By using this proprietary voice encoding, the modified HV3 payload 
structure contains the same 3.75 ms of speech information contained within a standard 
HV3 packet, while requiring only 120 of the 240 HV3 payload bits. Therefore, further 
data fields can be encoded into the HV3 payload to provide improved cordless 
telephone functionality. It is further understood that other voice encoding techniques 
which reduce the audio bitrate below that implemented in a standard HV3 link can be 
utilized as well, such as reduced-rate CVSD modulation or audio compression 
algorithms. Generally speaking, lower bitrate audio encoding techniques provide 
greater bandwidth within payload 300 for encoding of other types of information. 

In the payload structure of Figure 3, field 310 provides one byte of mux 
information, such as information specifying the voice data compression algorithm 
and/or other proprietary formatting information. Error detection/correction field 330 
contains 60 bits of CRC information for the audio data contained in field 320. Unlike 
the FEC provided by Bluetooth, CRC field 330 allows some errors to be corrected, and 
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further allows for uncorrectable errors to be detected such that erroneous audio 
information can be appropriately muted. Finally, 52-bit field 340 provides for a low-rate 
data channel which can be used for features such as the transmission of caller 
identification information. 

The system of Figure 2 can support up to three active links. Because the basic 
HV3 packet structure is maintained, the links may be any combination of proprietary 
voice links with payload structures such as that Figure 3, and conventional 
communications pursuant to the Bluetooth specification, such as data link 235 between 
base station 200 and personal computer 230. 

In accordance with another aspect of the invention, voice data can be 
transmitted using the Bluetooth data format links, rather than using the Bluetooth voice 
format links. By using data links, the transmission format can essentially be redefined 
completely. Figure 4 illustrates one possible payload structure of an embodiment 
based upon a DM3 link, according to this aspect of the invention. Field 41 0 provides 
two bytes for a header. As in the payload structure of Figure 3, a one-byte multiplex 
field is provided by field 420. Audio field 430 contains 80 bytes of encoded voice data, 
which corresponds to 20 ms of audio information when encoded using a 32 kbps 
ADPCM format. Finally, error detection/correct field 440 contains 40 bytes of CRC 
information which can be used to correct and/or detect errors imposed during 
transmission of the payload. As with the payload structure of Figure 3, the payload 
structure of Figure 4 could readily include voice data encoded using other techniques, 
(i.e. at other bitrates and using other algorithms), and a parallel data channel could 
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readily be defined over the same DM3 link by including allocation for data within the 
payload structure of Figure 4. 

However, the non-voice Bluetooth data links such as DM3 are normally 
asynchronous communication links (sometimes referred to as an Asynchronous 
Connection-Less ("ACL") link). Asynchronous links are typically undesirable for voice 
communications because of the timeliness required of the voice data transmission. 
Inasmuch as the normal operation of the ACL link is asynchronous, the recipient device 
automatically generates an ACK or NAK acknowledgment return signal to signify 
successful or unsuccessful reception of each data packet. The sender then retransmits 
the data unless and until an ACK signal is returned to the sender. However, for 
telephonic communications, voice data should preferably be transmitted and 
reproduced in near real time to enable efficient and natural conversation. Thus, only a 
certain limited amount of retransmission is allowable until the next voice data frame 
must be sent. 

An embodiment of the system, implementing a DM3 link with the payload 
structure illustrated in Figure 5 for voice communications, can overcome the problems 
of an asynchronous data format by forcing the format to behave in a somewhat 
synchronous manner. This can be achieved by using a mechanism within the Bluetooth 
specification known as isochronous data transmission, which limits the automatic 
retransmission of data. The mechanism uses a "flush" command to prevent 
retransmission of data after a certain period of time has elapsed even if an ACK has not 
been received. 
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By using the flush mechanism in conjunction with a DM3 link with the payload 
structure of Figure 4, the voice communications link can also gain the benefit of time 
and frequency diversity for increased robustness and reliability. The automatic 
retransmission of voice data occurs according to the ACK/NAK protocol until the data 
channel is flushed. The system can be configured to flush the data channel upon 
receipt of each new frame of audio data by the transmitting interface. Thus, the 
transmitter always sends new voice data immediately upon receipt, resulting in prompt 
transmission of the audio signal. Any retransmissions of already-sent data that take 
place prior to the flushing of the channel occur at a different time from the initial 
transmission, and also at a different carrier frequency since Bluetooth is a frequency- 
hopping standard, thereby providing frequency and time diversity to further improve the 
reliability and robustness of the communication system. 

The operation of this system is illustrated in Figure 5 which shows the 
transmission of four voice data packets, labelled V1 through V4, over a poor link, such 
as might be encountered in the presence of high-level radiofrequency interference. 
Each box represents a new Bluetooth packet, proceeding in time from left to right, with 
row 500 representing the transmitting device and row 510 representing the receiving 
device. Because Bluetooth is based upon a frequency-hopping radio protocol, 
transmissions during each box occur on a radio carrier frequency which differs from the 
previous transmission. The number of possible re-transmissions before the next voice 
packet is available (and therefore before the data link is flushed) will typically depend 
upon the amount of data traffic in the system as a whole and the amount of voice data 
carried in each packet. Typically, the gateway or base station acts as the master and 
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accordingly prioritizes required data transmissions. If transmission of extraneous data 
traffic with other devices is given greater priority than retransmissions of voice data, 
then such extraneous traffic may reduce or eliminate the opportunities for data re- 
transmissions before the link is flushed. 

For example, in Figure 5, data packet V1 is transmitted and successfully 
received during period 520. Thus, the receiving unit acknowledges successful receipt 
during period 521, and both units idle during periods 522 through 525, thus conserving 
power. At period 525, new data is received by the transmitting unit, so the data link is 
flushed. Then, during period 526, data packet V2 is transmitted to the receiving unit. 
Due to interference, the received data fails to satisfy the error detection and/or 
correction mechanisms implemented within the data packet. Accordingly, the receiving 
unit responds with a NAK signal during period 527. The transmitting unit, discovering 
that packet V2 has not been properly received, retransmits packet V2 during period 
528. The receiving unit receives V2, and responds with an ACK signal, such that both 
units idle during periods 530 and 531. At period 532, data packet V3 is transmitted. 
However, due to interference the packet is not received by the receiving unit. 
Accordingly, neither an ACK or NAK is sent back during period 533. The transmitting 
unit, pursuant to its data transmission protocol, automatically resends the data packet 
V3 during period 534. The transmission is successful, but the receiving unit's ACK 
response during period 535 is blocked. The transmitting unit, not having received an 
ACK for V3, makes a final attempt to transmit V3 during period 536. The data link is 
then flushed to ensure that V4 will be transmitted in a timely manner in period 538. 
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While the ACL link data packet payload of Figure 4 is based upon a DM3 link, it 
is understood that similar payloads could readily be derived for other known Bluetooth 
ACL types as well, such as DM1, DH1 , DH3, DM5 or DH5. However, while larger 
packets such as DM5 or DH5 have a very large capacity for voice data, such packets 
may not be appropriate for many telephony applications due to latency in the audio 
path. Each segment of speech must be compressed into a data packet, transmitted, 
and expanded back into audible information before it is heard by the recipient. Thus, a 
delay comprised of at least approximately the period of speech contained in one packet 
(required for buffering of the raw audio data before compression, transmission, 
decompression and playback) is imposed upon the communications channel. Because 
the larger packets would contain comparatively lengthy periods of speech in each 
packet, the inherent delay in the communications channel may result in undesirable 
audible characteristics. Therefore, packet types such as DM3 (using either 64kfa/s or 
32kb/s voice encoding) or DH1 (using 32kb/s) may be effective for many cordless 
telephony applications. 

For a cordless telephone system implemented using DM3 links and 64kb/s voice 
encoding with the payload structure of Figure 4, each DM3 packet holds 10ms of 
encoded voice data along with 40 bytes of CRC error detection/correction information. 
Thus, given the time slot period of Bluetooth, a packet would be needed in each 
direction every 16 slots to maintain an uninterrupted full-duplex audio link. Up to 2 full- 
duplex voice links could be provided on a Bluetooth bearer, with some capacity for 
other data links as well. For one active voice link, several retransmissions may be 
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possible if needed as a result of a NAK, while for two active voice links only one 
retransmission would be possible. 

For a cordless telephone system implemented using DM3 links and 32kb/s voice 
encoding with the payload structure of Figure 4, each DM3 packet could hold 20ms of 
encoded voice data along with 40 bytes of CRC error detection/correction information. 
Thus, given the time slot period of Bluetooth, a packet would be needed in each 
direction every 32 slots. Up to 5 full-duplex voice links could be provided, with some 
capacity for other data links as well. Moreover, a number of packet retransmissions 
may be available, depending upon the number of active links in the system. It is 
believed that an audio latency of approximately 20ms, as is inherent in such a system, 
should be acceptable for a voice communication link. 

One embodiment of a Bluetooth-based cordless telephony system using ACL 
links is illustrated in Figure 6. Base unit 600 communicates with cordless handsets 610 
and 620 using DM3 links with the payload structure of Figure 4 for voice transmission. 
Furthermore, base unit 600 is capable of simultaneously communicating with a 
Bluetooth-enabled digital device such as personal computer 630 using a DM1 link. 

Figure 7 is a functional block diagram of the downlink between base unit 600 and 
cordless handset 610 connected by DM3 link 700, whereby voice signals are 
transmitted from the PSTN to handset 610. An analog audio signal is receiving from 
the PSTN at audio front end 710, and conveyed to PCM codec 715 for digitization. The 
PCM voice data is then conveyed to link manager 720. Link manager 720 processes 
the audio information in accordance with the proprietary link type selected for the 
communication link. For example, in the illustrated example, link manager 720 may 
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determine and insert the CRC, mux and header fields. In a system where link 700 was 
a modified HV3 with a payload structure of Figure 3, then the link manager could also 
insert data content corresponding to the relevant traffic for parallel data channel 340. 

Link manager 720 outputs encoded payload data to packet encoder 725. Packet 
encoder 725 performs the packet formatting according to the type of link upon which 
link 700 is based, such as inserting the packet header and the encoded payload data 
into their appropriate positions within the packet. The formed packet is then conveyed 
to Bluetooth radio unit 730, which transmits the information wirelessly via link 700. 

Handset radio 750 receives the transmitted information and outputs the packet to 
packet decoder 755. Packet decoder 755 extricates the encoded payload information, 
which is then conveyed to handset link manager 760. Link manager 760 further 
extracts the encoded audio data from the encoded payload, and sends the audio data 
to PCM codec 765. Codec 765 converts the digital audio data into an analog audio 
signal and sends the signal to audio front-end 770, which may include a speaker 
positioned within the telephone handset. In this way, an audio signal can be conveyed 
between devices using a Bluetooth bearer, while implementing proprietary features 
capable of providing a more robust and full-featured cordless telephony solution. 

The uplink from handset 610 to base station 600 operates analogously to the 
downlink illustrated in Figure 7. Furthermore, the functional block diagram of Figure 7 
can be readily implemented to also implement the transmission of voice data using a 
link based upon a SCO Bluetooth link, such as that illustrated in Figures 2 and 3. It is 
further contemplated that the Bluetooth baseband operations can readily be 
implemented in hardware, software or a combination of both. Many other 
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configurations could be readily implemented in place of that of Figure 7 in which the 
actual handling of the encoded voice data is performed in higher layers. 

The foregoing description and drawings merely explain and illustrate the invention 
and the invention is not limited thereto except insofar as the appended claims are so 
limited, inasmuch as those skilled in the art, having the present disclosure before them 
will be able to make modifications and variations therein without departing from the scope 
of the invention. 
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I claim: 

1 . A method for transmitting digitized audio data from a first wireless device to a 
second wireless device, the method comprising the steps of: 

generating an error detection code based upon the digitized audio data; 

generating encoded payload information comprised of the digitized audio data and 
the error detection code; 

forming a data packet having the structure of a Bluetooth synchronous connection- 
oriented link packet in which the payload is comprised of the encoded payload 
information; 

transmitting the data packet from the first device to the second device via a 
Bluetooth synchronous connection-oriented link; 

extracting the encoded payload from the data packet by the second wireless 
device; 

detecting that the payload was received without errors by implementing an error 
detection protocol associated with the error detection code transmitted within the encoded 
payload. 

2. The method of claim 1 , in which the the digitized audio data is encoded at a bit 
rate less than approximately 64 kilohertz. 

3. The method of claim 1 . in which the audio data is encoded in an ADPCM format at 
a bitrate of approximately 32 kHz. 
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4. The method of claim 1 , in which the audio data is encoded using a compression 
algorithm. 

5. The method of claim 1 , in which the data packet is formed having the structure of a 
Bluetooth HV3 packet. 

6. The method of claim 1 , which method further includes the preceding step of: 
determining that the first and second devices are capable of communications using 

a non-standard link that is derived from a Bluetooth Synchronous Connection-Oriented 
comrnun ications lin k. 

7. The method of claim 6, in which the step of determining that the first and second 
devices are capable of communicating includes the substep of utilizing the Bluetooth 
Service Discovery Protocol. 

8. A method of forming a packet containing audio data for transmission using a 
Bluetooth synchronous connection-oriented communication link, the method comprising 
the steps of: 

selecting digitized audio data encoded at a bitrate of less than 64 kHz; 

appending an error detection field to the encoded audio data; 

forming a packet payload comprised of the selected digitized audio data and the 
error detection field, the packet payload being sized to match the payload capacity of the 
synchronous connection-oriented communications link; 
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inserting the formed packet payload into said packet. 

9. A method of forming a packet containing audio data for transmission using a 
Bluetooth asynchronous connectionless communication link, the method comprising the 
steps of: 

selecting digitized audio data encoded at a predetermined bit rate; 
determining the contents of an error detection field based upon the contents of the 
digitized audio data; 

forming a packet payload comprised of the selected digitized audio data and the 
error detection field, the packet payload being sized to match the payload capacity of the 
asynchronous connectionless communication link; 

inserting the formed packet payload into said packet. 

1 0. A method for transmitting digitized audio data from a first wireless device to a 
second wireless device, the method comprising the steps of: 

receiving digized audio data at the transmitter of the first device; 

generating an error detection code based upon the digitized audio data; 

generating encoded payload information comprised of the digitized audio data and 
the error detection code; 

forming a data packet having the structure of a Bluetooth asynchronous 
connectionless link packet in which the payload is comprised of the encoded payload 
information; 
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transmitting the data packet from the first device to the second device via a 
Bluetooth asynchronous connectionless iink; 

flushing the asynchronous connectionless link approximately when the first device 
transmitter receives new digitized audio data; 

extracting the encoded payload from the data packet by the second wireless 

device; 

detecting that the payload was received without errors by implementing an error 
detection protocol associated with the error detection code transmitted within the encoded 
payload. 

1 1 . The method of claim 1 0, in which the data packet is automatically retransmitted by 
the first device unless and until an acknowledge signal is received from the second 
device, and/or the asynchronous connectionless link is flushed. 
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